Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add custom hiera backend for trocla #15

Merged
merged 1 commit into from
Oct 18, 2015
Merged

Add custom hiera backend for trocla #15

merged 1 commit into from
Oct 18, 2015

Conversation

michaelweiser
Copy link
Contributor

I wrote a custom hiera backend for trocla. Would you be interested in it?

I made some design decisions open for discussion:

  • To get additional parameters for the trocla function on a per-password basis, the lookup function of the custom backend does itself do hiera lookups.
  • To prevent loops, the backend only reacts to namespace trocla::password:: and does all additional lookups into trocla::options::

This means that password creation has to be triggered via explicit hiera function interpolation lookups such as:

kerberos::kdc_database_password: "%{hiera('trocla::password::kdc_database_password')}"

I looked into just adding a "%{trocla('<key>')}" function but there's no API for that and the existing functions hiera and scope are pretty hard-coded in the hiera source. Getting trocla-support in there without adding a whole extension function API is unlikely.

  • It implements the actual hiera hierarchy by pre-pending the hiera path to the trocla key as hiera/<source>/<trocla_key>. This way, the same trocla key could yield different passwords for different groups of machines. I'm not sure, how much use this would actually be in practice. Also, that key would need to be initialised externally, e.g by calling trocla('hiera/osfamily/Debian/jessie/root' in site.pp. Alternatively we could use hiera's concept of datafiles to look into different trocla password stores. But this would need somehow providing different troclarcs as well.

Only reacts to key namespace trocla::password::<trocla_key>. Looks up
additional parameters via hiera itself as
trocla::options::<trocla_key>::format (string) and
trocla::options::<trocla_key>::options (hash). Looks for <trocla_key> in
trocla as hiera/<source>/<trocla> with <source> iterating over the
configured hiera hierarchy. If not found, creates and returns a new
password with trocla key <trocla_key>.

example entry in hiera.yaml:

backends:
  - ...
  - trocla
trocla:
  - configfile: /etc/puppet/troclarc.yaml
  - format: plain
  - options:
    length: 16

example usage in hiera yaml file:

kerberos::kdc_database_password: "%{hiera('trocla::password::kdc_database_password')}"
trocla::options::kdc_database_password::format: 'plain'
trocla::options::kdc_database_password::options:
  length: '71'

Only reacts to key namespace trocla::password::<trocla_key>. Looks up
additional parameters via hiera itself as
trocla::options::<trocla_key>::format (string) and
trocla::options::<trocla_key>::options (hash). Looks for <trocla_key> in
trocla as hiera/<source>/<trocla> with <source> iterating over the
configured hiera hierarchy. If not found, creates and returns a new
password with trocla key <trocla_key>.

example entry in hiera.yaml:
backends:
  - ...
  - trocla
trocla:
  - configfile: /etc/puppet/troclarc.yaml
  - format: plain
  - options:
    length: 16

example usage in hiera yaml file:
kerberos::kdc_database_password: "%{hiera('trocla::password::kdc_database_password')}"
trocla::options::kdc_database_password::format: 'plain'
trocla::options::kdc_database_password::options:
  length: '71'
@duritong
Copy link
Owner

duritong commented Oct 8, 2015

Hi

in general I like your Idea, although I haven't yet looked into it in detail.
But I was already thinking a couple of times how this could be achieved and I like your idea, but I'd like to reflect a bit more on it.

Nevertheless, I really appreciate this PR! Thanks a lot!

@duritong
Copy link
Owner

I like it, I guess I will do a few optimizations, but in general I'm fine. Thanks a lot!

duritong added a commit that referenced this pull request Oct 18, 2015
Add custom hiera backend for trocla
@duritong duritong merged commit 83814de into duritong:master Oct 18, 2015
@duritong
Copy link
Owner

Could you have a look at cbd411b and tell me whether it still works and what you think off.

The only thing left is whether we should hash-merge the options on the trocla.password(), as this might not be expected and I'm not sure if we actually need that and hence should just stick with the normal hiera lookup behavior.

@michaelweiser
Copy link
Contributor Author

Well, it certainly looks a lot more elegant now and seems to work just fine after applying #16.

As for hash merge vs. priority first lookups: I'm a total sucker for hash merges because I like the flexibity and conciseness (non-redundancy) in spite of the potential for occasional confusion due to unexpected interactions or precedence. An adminttedly constructed but IMO quite conceivable real world example: I need a password with length 16 chars on standard systems (so I have a slight chance of remembering them) but 32 chars for those in the DMZ (because some policy says so). I also need it to be shellsafe on Debian boxes because their funky default of /bin/sh being dash instead of bash lets all hell break loose otherwise:
hiera.yaml:

:hierarchy:
  - "osfamily/%{::osfamily}"
  - dmz
  - common

common.yaml:

service_pwd: "%{hiera('trocla::password::service_pwd')}"
trocla::options::service_pwd::format: 'plain'
trocla::options::service_pwd::options:
  length: '16'

dmz.yaml:

trocla::options::service_pwd::options:
  length: '32'

osfamily/Debian.yaml:

trocla::options::service_pwd::options:
  charset: 'shellsafe'

@duritong
Copy link
Owner

I'm also fine with the hash_merge behavior and use it a lot. Experience just tell me, that a lot of people struggle with grasping the concept behind it. let's leave it like that for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants